1. Field of the Invention
This invention relates to memory management and more particularly to methods of cache bounded reference counting.
2. Description of Background
A problem with the existing art is that all of the languages that have an automatic memory management, such as Java, C#, and Python, suffer from performance issues. That means much memory is allocated on top of the heap (i.e., of unused memory) normally, and the heap grows very rapidly. Regardless of whether objects that are allocated are used for a long period of time or for a very short period of time, all new objects are allocated on top of this heap, and the re-use of memory space occupied by objects that are no longer used occurs only after a garbage collection is run. Normally this growth of the heap by repeatedly piling new memory objects on top of the heap, means that memory areas are accessed/used that are not represented in the cache at this moment. This causes a cache miss to occur, which causes a long delay as a consequence.
Disadvantages of the standard way to allocate memory on top of the growing heap for such languages with automatic memory management is the quite significant number of cache misses for each new cache line that is accessed which is not stored in the cache and is new for the program. Thus, there is memory consumption because there is no re-use of memory that is no longer used until the garbage collection is run. This is a disadvantage of the existing art compared to languages of explicit memory management such as C or C++. For languages with automatic memory management, such as Java, it is necessary to run frequent garbage collections in order to compact the heap again and to regain memory areas for new allocation.
Efforts are currently on-going in the industry and research in universities to address those issues for languages such as Java. For example, efforts are currently on-going to modify Java byte code to recognize such re-use patterns upfront such as by adding free( ) instructions automatically into the byte code. Then a so-called escape analysis is performed that identifies objects which are bound to the scope of a specific method. Instead of allocating such objects on the heap, they are allocated on a stack frame of that particular method which is quite likely to be re-used more often and therefore more likely to reside in the cache. This also gives a relief to the heap which is not growing as fast as it otherwise might be, but this relief is not complete. This is available only for objects which are identifiable upfront and strictly related to a specific method (or functional procedure in which it is used) and cannot escape that method.